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In  this  article  we  consider  the  polymorphic  type  checking  of  an  imperative  language.  Our  lan¬ 
guage  contains  variables ,  first-class  references  (pointers),  and  first-class  functions.  Variables,  as 
in  traditional  imperative  languages,  are  implicitly  dereferenced,  and  their  addresses  (L- values)  are 
not  first-class  values.  Variables  are  easier  to  type  check  than  references  and,  in  many  cases,  lead 
to  more  general  polymorphic  types.  We  present  a  polymorphic  type  system  for  our  language  and 
prove  that  it  is  sound.  Programs  that  use  variables  sometimes  require  weak  types,  as  in  Tofte’s 
type  system  for  Standard  ML,  but  such  weak  types  arise  far  less  frequently  with  variables  than 
with  references. 

Categories  and  Subject  Descriptors:  D.3.3  [Programming  Languages]:  Language  Constructs 
and  Features;  F.3.3  [Logics  and  Meanings  of  Programs]:  Studies  of  Program  Constructs — 

type  structure 
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Additional  Key  Words  and  Phrases:  Assignment,  references,  variables 


1.  INTRODUCTION 

Polymorphic  type  checking  of  a  language  with  first-class  references  (pointers)  is  a 
difficult  problem,  as  can  be  seen  by  the  many  type  systems  proposed  for  typing  ref¬ 
erences  in  Standard  ML  [Damas  1985;  Greiner  1993;  Hoang  et  al.  1993;  Leroy  1993; 
Leroy  and  Weis  1991;  Talpin  and  Jouvelot  1992;  Tofte  1990;  Wright  1995].  But 
many  imperative  programs  do  not  require  the  power  of  first-class  references — they 
merely  manipulate  values,  other  than  pointers,  as  the  contents  of  local  variables. 
Unfortunately,  if  local  variables  must  be  created  using  first-class  references,  then 
whatever  mechanism  is  used  to  enforce  the  correct  typing  of  references  is  likely  to 
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adversely  affect  the  typing  of  programs  that  really  only  need  variables.  Thus,  it  is 
beneficial  to  introduce  an  additional  letvar  construct  to  allocate  variables,  which 
are  implicitly  dereferenced  and  whose  addresses  (L-values)  are  not  first-class  values. 

Aside  from  their  typing  benefits,  variables  are  also  of  interest  because  their  im¬ 
plicit  dereferencing  is  a  syntactic  convenience,  and  because  they  are  at  the  core  of 
mainstream  imperative  languages. 

The  idea  of  including  variables  in  a  polymorphic  language  is  not  new.  In  fact, 
Edinburgh  LCF  ML  [Gordon  et  al.  1979]  had  a  letvar  construct,  which  it  called 
letref .  But  it  did  not  have  first-class  references,  and  according  to  Tofte  [1990],  its 
type  system  was  never  proved  sound. 

2.  AN  INFORMAL  DESCRIPTION  OF  THE  TYPE  SYSTEM 

The  language  we  consider  is  the  core  ML  of  Damas  and  Milner  [1982]  together  with 
first-class  references,  created  by  ref,  variables,  created  by  letvar,  and  imperative 
constructs  such  as  while  loops.  The  construct  letvar  x  :  =  a  in  b  binds  x  to  a 
new  cell  initialized  to  the  value  of  a.  The  scope  of  the  binding  is  b,  and  the  lifetime 
of  the  cell  is  unbounded.  Conversion  of  L-values  to  i?-values  is  implicit,  so  that 
letvar  x  :=  e  in  x  is  equivalent  to  e. 

The  types  of  our  system  are  stratified  into  three  levels.  There  are  the  ordinary 
r  (data  types)  and  a  (type  schemes)  type  levels  of  Damas  and  Milner’s  system 
and  a  new  level  called  phrase  types  containing  a  types  and  types  of  the  form  r  var 
for  variables.  Unlike  references,  variables  are  not  first-class  values.  As  in  Tofte’s 
system  for  Standard  ML  [Tofte  1990],  type  variables  are  partitioned  into  weak  and 
strong  variables.1  Strong  type  variables  are  written  a  and  weak  ones  _a.  A  weak 
type  variable  cannot  be  instantiated  with  a  type  containing  strong  type  variables. 
As  in  Tofte’s  system,  a  weak  type  variable  can  be  generalized  only  when  it  appears 
in  the  type  of  a  syntactic  value,  that  is,  an  identifier,  a  literal,  or  a  A-abstraction. 

Because  variable  addresses  are  not  first-class  values,  it  is  easier  to  keep  track 
syntactically  of  operations  on  variables  than  operations  on  references.  As  a  result, 
many  useful  functions  that  use  letvar  can  be  given  fully  polymorphic  types.  For 
example,  imperative  list  reversal  can  be  defined  as 

fun  irev  1  =  letvar  a  :  =  1  in 
letvar  b  :=  []  in 

while  not  (null  a)  do 
(  b  : =  (hd  a)  : :  b; 
a  : =  tl  a) ; 
b 

end  end 

Two  local  variables  a  and  b  are  declared,  yet  the  function  is  assigned  fully  poly¬ 
morphic  type  Va  .  a  list  —>■  a  list  in  our  system.  Thus  irev[]  is  a  polymorphic  list 
of  type  Va  .  a  list.  Consider  a  definition  of  irev  in  Standard  ML: 

fun  irev  1  =  let  val  a  =  ref  1  in 
let  val  b  =  ref  []  in 


1Tofte  actually  calls  them  imperative  and  applicative  variables,  respectively. 

ACM  Transactions  on  Programming  Languages  and  Systems,  Vol.  18,  No.  3,  May  1996,  Pages  254-267. 


256  •  Geoffrey  Smith  and  Dennis  Volpano 

while  not  (null  (!a))  do 
(  b  :=  (hd  ( !a))  : :  ( !b) ; 
a  :=  tl  ( !a)) ; 

!b 

end  end 

Now  the  use  of  local  variables  is  reflected  in  the  type  of  irev.  Standard  ML  would 
give  it  type  V_a  .  _a  list  —>■  ja  list,  where  ja  is  an  imperative  type  variable,  and 
Standard  ML  of  New  Jersey  would  give  it  type  Va1  .  a1  list  — >■  a1  list  where  a1  is 
a  weak  type  variable.  The  weak  variable  indicates  that  applying  irev  once  may 
create  a  reference  whose  type  involves  a.  In  each  case,  consequently,  irev[]  is  not 
a  polymorphic  list. 

One  has  the  option  of  defining  irev  in  our  language  using  ref  instead  of  letvar, 
but  this  would  needlessly  constrain  polymorphism.  Our  system  would  then  give  it 
the  Standard  ML  type  V_a  .  ja  list  —>  ja  list,  and  the  application  irev[]  would  no 
longer  be  polymorphic.  In  fact,  if  one  always  uses  let  and  ref  in  our  system  rather 
than  letvar,  then  our  system  “degenerates”  to  Tofte’s  system  for  Standard  ML. 

Our  system  also  does  well  on  programs  that  cause  problems  for  the  “syntactic 
values”  type  system  advocated  by  Wright  [1995].  Consider  make  Count  Fun  which 
takes  a  function  /  as  input  and  returns  both  a  counting  version  of  /  and  a  function 
to  read  the  counter: 

fun  makeCountFun  f  =  letvar  x  : =  0  in 
(fnz=>x  :=x+  1;  f  z, 
fn  ()  =>  x) 

end 

Our  system  gives  makeCountFun  type 

Va,  /?.  (a  —*■/?)—*■  (a  —*■/?)  x  ( unit  —>■  ini), 

and  an  application  such  as  makeCountFun  hd  is  polymorphic.  If  makeCountFun  is 
written  using  let  and  ref,  then  makeCountFun  hd  is  also  polymorphic  in  Tofte’s 
system.  But  in  Wright’s  system,  makeCountFun  hd  is  monomorphic  because  only 
syntactic  values  are  polymorphic,  and  a  function  application  is  not  a  syntactic  value. 

Programs  that  use  letvar  but  not  ref  may  still  require  weak  types.  The  rule 
is  that  a  letvar-bound  identifier  must  be  given  a  weak  type  if  it  occurs  in  a  A- 
abstraction  within  its  scope.  This  rule  comes  into  play  when  functions  create  “ob¬ 
jects”  or  “own  variables.”  For  example,  consider  a  function  that  creates  a  stack 
object  with  push  and  pop  operations  accessing  a  shared  stack: 

fun  makestack  x  = 
letvar  stk  : =  x  in 

( fn  v  =>  stk  :=  v  ::  stk, 
fn  ()  =>  stk  :=  tl  stk) 

end 

It  is  unsound  to  give  makestack  the  strong  polymorphic  type 
Va  .  a  list  —>■  (a  —>■  unit)  x  ( unit  —>■  unit) 
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because,  if  the  application  makestack  []  were  polymorphic,  the  resulting  push  op¬ 
eration  could  be  called  with  values  of  different  types,  leading  to  a  nonhomogeneous 
stack.  In  our  system,  since  stk  occurs  inside  a  A-abstraction  within  its  scope,  it 
must  be  given  a  weak  type.  This  allows  makestack  to  be  given  only  the  weak 
polymorphic  type 

V_a  .  _a  list  —>■  (_a  — >■  unit)  x  ( unit  —>■  unit). 

The  ability  to  give  makestack  a  weak  polymorphic  type  makes  our  system  sub¬ 
stantially  better  than  Edinburgh  LCF  ML  on  cases  of  this  kind.  In  LCF  ML,  a 
letvar-bound  identifier  must  be  given  a  monotype  (i.e. ,  a  type  with  no  variables) 
if  it  is  assigned  to  within  a  A-abstraction  within  its  scope  (restriction  2 ib  [Gor¬ 
don  et  al.  1979,  p.  49]).  Hence,  since  stk  is  assigned  to  within  the  push  and  pop 
operations,  LCF  ML  requires  stk  to  be  annotated  with  a  monotype.  This  forces 
makestack  to  be  monomorphic. 

Finally,  typings  of  purely  functional  programs  in  our  system  are  preserved  as 
they  are  in  the  type  systems  for  Standard  ML  and  Standard  ML  of  New  Jersey. 
No  labels  or  other  annotations  are  required  on  arrow  types  as  they  are  in  closure 
[Leroy  and  Weis  1991]  and  effect  [Talpin  and  Jouvelot  1992;  Wright  1992]  typing. 

3.  A  FORMAL  TREATMENT  OF  THE  TYPE  SYSTEM 

The  syntax  of  our  language  is  given  below.  Following  Tofte  [1990],  we  distinguish 
a  subset  of  the  expressions  called  Values.  Evaluating  a  value  does  not  allocate  any 
new  cells;  this  property  is  exploited  by  the  type  system. 

( Expressions )  e  ::=  v  \  l  |  ei  e^  |  let  x  =  ei  in  e^  \ 
letvar  x  :=  ei  in  e 2  |  ei  :=  e 2  | 
ref  e  |  *e  | 

ei;e2  |  while  ei  do  e 2  |  if  ei  then  e 2  else  63 
( Values )  v  ::=  x  \  c  \  r  \  Xx.e 

Metavariable  x  ranges  over  identifiers,  and  metavariable  c  ranges  over  literals, 
such  as  true,  false,  and  unit.  Metavariables  l  and  r  range  over  variable  locations 
and  reference  locations,  respectively.2  Notice  that  unlike  reference  locations,  vari¬ 
able  locations  are  not  values.  The  *  operator  is  used  to  dereference  a  reference;  it 
is  similar  to  !  in  Standard  ML.  Finally,  we  remark  that  the  sequential  composition 
ei ;  62  could  be  taken  as  syntactic  sugar  for  let  z  =  e  1  in  e2,  where  z  is  new. 

The  types  of  the  language  are  stratified  as  follows. 

r  ::=  a  |  bool  \  unit  |  r  ref  |  r  —>■  t'  ( data  types) 
a  ::=  Va  .  a  |  r  ( type  schemes) 

p  ::=  <7  |  r  var  ( phrase  types) 

Metavariable  a  ranges  over  type  variables.  Type  variables  are  partitioned  into  weak 
and  strong  type  variables,  written  _a  and  a  respectively.  These  variables  correspond 
to  the  imperative  and  applicative  type  variables  respectively  of  Tofte’s  system.  We 


2Locations  will  not  in  fact  occur  in  user  programs.  They  are  included  as  expressions  solely  for  the 
purpose  of  simplifying  the  semantics,  as  will  become  clear  in  Section  4. 
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say  a  data  type  r  is  weak  iff  every  type  variable  occurring  in  it  is  weak.  Type  r  ref 
(r  var)  is  the  type  of  reference  ( variable )  locations  storing  values  of  type  r. 

The  rules  of  the  type  system  are  formulated  as  they  are  in  Harper’s  system 
[Harper  1994]  and  are  given  in  Figure  1.  It  is  a  deductive  proof  system  used  to 
assign  types  to  expressions.  Typing  judgments  have  the  form 

\;j\~e:p 

meaning  that  expression  e  has  type  p  assuming  that  the  free  identifiers  and  locations 
of  e  have  the  types  prescribed  by  7  and  A,  respectively.  More  precisely,  metavariable 
7  ranges  over  identifier  typings,  which  are  finite  functions  mapping  identifiers  to 
phrase  types;  j(x)  is  the  phrase  type  assigned  to  x  by  7,  and  j[x  :  p]  is  a  modified 
identifier  typing  that  assigns  phrase  type  p  to  x  and  assigns  phrase  type  j(xr)  to 
any  identifier  x'  other  than  x.  Metavariable  A  ranges  over  location  typings,  which 
are  finite  functions  mapping  locations  to  data  types.  The  notational  conventions 
for  location  typings  are  similar  to  those  for  identifier  typings. 

The  generalization  of  a  data  type  r  relative  to  A  and  7,  written  Close\n(T),  is  the 
type  scheme  Vd  .  r,  where  d  is  the  set  of  all  type  variables  occurring  free  in  r  but 
not  in  A  or  in  7.  We  write  A  b  e  :  r  and  CIosc\(t)  when  7  =  0.  A  restricted  form 
of  generalization,  written  AppClosey^lr),  is  defined  to  be  the  same  as  Close\n(T) 
except  that  only  strong  type  variables  are  generalized;  any  weak  ones  remain  free. 

A  substitution  is  a  mapping  S  from  type  variables  to  data  types  such  that  if  _a 
is  in  the  domain  of  S ,  then  S^.a)  is  weak.  Substitutions  extend  homomorphically 
to  data  types. 

We  say  that  r'  is  a  generic  instance  of  Vd  .  r,  written  Vd  .  r  >  r' ,  if  there  exists 
a  substitution  S  with  domain  d  such  that  St  =  r'.  We  extend  this  definition  to 
type  schemes  by  saying  that  a  >  a'  if  for  all  r,  it'  >  r  implies  <7  >  r. 

Finally,  we  write  A;  7  b  e  :  a  iff  A;  7  b  e  :  r  whenever  <7  >  r. 

Rules  (L-VAL)  and  (ASSIGN)  should  be  contrasted  with  the  analogous  rules  in 
Standard  ML.  In  our  system,  if  e  :  r  ref,  then  *e  :  r  var ;  in  Standard  ML,  !e  :  r. 
In  our  system,  the  left-hand  side  of  an  assignment  must  have  a  type  of  the  form 
r  var ;  in  Standard  ML,  it  must  have  a  type  of  the  form  r  ref .  Hence  if  x  :  mt  ref , 
then  one  increments  the  cell  that  x  points  to  by  writing 

*x  :=  *x  +  1 


in  our  system  and 


x  :=  \x  +  1 


in  Standard  ML. 

We  do  not  adopt  Standard  ML’s  typings  of  references  because  this  would  lead 
to  ambiguity.  For  suppose  that  we  had  two  rules  for  typing  assignments:  rule 
(ASSIGN)  and  Standard  ML’s  rule, 

A;  7  b  ei  :  r  ref,  A;  7  h  e2  :  r 
A;  7  b  e\  :=  e 2  :  unit 


Then  the  expression 


letvar  p  :=  ref  0  in  A x.p  :=  x 
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(IDENT)  A;  7  h  x  :  r  7(2;)  >  T 

(VAR-ID)  A;  7  h  x  :  r  var  7(2;)  =  r  var 

(REFLOC)  A;  7  I -  r  :  t  ref  A (r)  =  r 

(VARLOC)  A;  7  h  I  :  r  var  \(i)  =  t 

(LIT)  A;  7  h  true  :  bool 

A; 7  h  false  :  bool 
A;  7  h  unit  :  unit 

(^-INTRO)  A;  y[x  :  77]  h  e  :  T2 

A;  7  h  Ax.  e  :  n  — »■  T2 

(— s-ELIM)  A;  7  h  ei  :  ri  — »■  r2,  A;  7  h  02  :  ri 

A;  7  h  ei  e2  :  r2 

(LET-VAL)  A;  7  h  r  :  n,  A;  7(2:  :  CloseA^)^)]  he:r2 
A;  7  h  let  1  =  9  in  e  :  r2 

(LET-ORD)  A;  7  I-  ei  :  n,  A;  7[r  :  AppClosex.,l(ri )]  l~  e2  :  r2 
A;  7  h  let  x  =  ei  in  e2  :  r2 

(LETVAR)  A;  7  h  ei  :  ri,  A;  7(2:  :  n  rar]  h  e2  :  r2 

If  x  occurs  in  a  A-abstraction  in  e2,  then  n  is  weak. 
A;  7  h  letvar  x  :=  ei  in  e2  :  r2 

(R-VAL)  A;  7  h  e  :  r  nar 

A;  7  h  e  :  t 

(ASSIGN)  A;  7  h  ei  :  r  var,  A;  7  h  e2  :  r 
A;  7  h  ei  :=  e2  :  unit 

(REF)  A;  7  h  e  :  r,  r  is  weak 

A;  7  h  ref  e  :  r  ref 

(L-VAL)  A;  7  h  e  :  r  re/ 

A;  7  h  +e  :  r  var 

(COMPOSE)  A;  7  I-  ei  :  n,  A;  7  I-  e2  :  r2 
A;  7  h  ei ; e2  :  r2 

(WHILE)  A;  7  I-  ei  :  bool,  A;  7  I -  e2  :  r 

A;  7  h  while  ei  do  e2  :  unit 

(IF)  A;  7  h  ei  :  bool,  A;  7  h  e2  :  r,  A;  7  h  e3  :  r 

A;  7  h  if  ei  then  e2  else  e3  :  t 

Fig.  1.  Rules  of  the  type  system. 
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in  which  p  has  type  int  ref  var  would  be  ambiguous.  If  x  had  type  int  ref ,  then 
the  assignment  would  make  p  point  to  a  new  cell.  On  the  other  hand,  if  x  had  type 
int,  then  an  ff-value  conversion  of p  could  give  it  type  int  ref,  and  the  assignment 
would  change  the  contents  of  the  cell  to  which  p  points.  But  with  our  rules  there 
is  no  ambiguity.  Just  as  in  C,  we  write  p  :=  x  to  make  p  point  to  a  new  cell  and 
*p  :=  x  to  change  the  contents  of  the  cell  to  which  p  points. 

Note  also  how  the  type  stratification  and  typing  rules  force  variables  to  be  implic¬ 
itly  dereferenced,  except  when  they  occur  as  the  left-hand  side  of  an  assignment. 
Consider,  for  example,  the  typing  of  letvar  x  :=  e\  in  e^.  Rule  (LETVAR)  forces 
C2  to  be  given  a  data  type  T2,  not  a  phrase  type.  So  if  e 2  is  x  (with  type,  say,  T\  var), 
then  we  are  forced  to  use  rule  (R-VAL)  to  derive  the  typing  x  :  T\  before  we  can 
type  the  entire  letvar.  Indeed,  one  can  readily  see  that  the  only  expressions  that 
can  get  types  of  the  form  r  var  are  identifiers,  variable  locations,  and  expressions 
of  the  form  *e. 


4.  SEMANTICS  AND  SOUNDNESS 

In  this  section,  we  establish  the  soundness  of  our  type  system  using  the  framework  of 
Harper  [1994],  who  built  upon  the  earlier  work  of  Tofte  [1990],  Wright  and  Felleisen 
[1994],  and  Leroy  and  Weis  [1991]. 

First  we  give  a  structured  operational  semantics  for  our  language.  An  expression 
is  evaluated  relative  to  a  memory  p,  which  is  a  finite  function  from  locations  to 
values.  The  contents  of  a  location  l  £  dom(p)  is  the  value  p(l),  and  we  write 
p[l  :=  i>]  for  the  memory  that  assigns  value  v  to  location  l,  and  value  p(l')  to  a 
location  V  yt  /.  Note  that  p[l  :=  i>]  is  an  update  of  p  if  /  £  dom(p)  and  an  extension 
of  p  if  /  dom(p). 

Our  evaluation  rules  are  given  in  Figure  2.  They  allow  us  to  derive  judgments  of 
the  form 


p  |-  e  =y  v ,  p! 

which  is  intended  to  assert  that  evaluating  closed  expression  e  in  memory  p  results 
in  value  v  and  new  memory  p' .  We  write  [e' /x\e  to  denote  the  capture-avoiding 
substitution  of  e'  for  all  free  occurrences  of  x  in  e.  The  use  of  substitutions  in  rules 
(APPLY),  (BIND),  and  (BINDVAR)  allows  us  to  avoid  environments  and  closures 
in  the  semantics,  so  that  the  result  of  evaluating  an  expression  is  just  another 
expression. 

We  now  turn  to  soundness.  The  basic  idea  is  to  show  that  if  h  e  :  r  and  h  e  => 
v,p',  then  h  v  :  r,  a  property  called  subject  reduction.  But  since  e  can  allocate 
locations  and  since  these  locations  can  occur  in  v,  the  conclusion  must  actually  be 
that  there  exists  a  location  typing  A'  such  that  A'  h  v  :  r  and  such  that  p'  :  A'.  The 
latter  condition  asserts  that  A'  is  consistent  with  p';  more  precisely,  we  say  that 
p  :  A  if  dom(p)  =  dom( A)  and  for  every  l  £  dom(p),  A  h  p(l)  :  A (/). 

It  is  the  location  typing  A'  that  makes  soundness  delicate.  As  observed  by  Tofte, 
we  may  generalize  a  type  variable  a  in  typing  h  e  :  r,  only  to  find  that  a  occurs 
(free)  in  A',  and  therefore  cannot  be  generalized  in  typing  A'  h  v  :  r. 
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(VAL) 

fl\~  V  =$■  V,  fl 

(APPLY) 

M  P  ei  =>■  Xx.  e\  ,  mi 
|ii  h  e2  =)•  v2,fi2 

M 2  P  [v2/x\e\  =>•  r,  /t' 

|i  h  ei  e2  «,  n' 

(BIND) 

fife  i  =>•  Hi,  /tii 

Mi  P  [ri/r]e2  =S  H2,  M2 

M  P  let  x  =  ei  in  e2  =S  ii2,  M2 

(BINDVAR) 

M  P  ei  =>•  «i,  Mi 

1  0  dom(fi  1 ) 

Mi :=  m]  P  [Vde2  =S  112,  M2 

M  P  letvar  x  :=  t\  in  e2  =S  112,  M2 

(CONTENTS) 

M  P  1  A  m(0> 

(UPDATE) 

M  P  e  4  t,  m’ 

M  |-  |  :=  e  =>•  unit,  mI^  :=  11] 

M  P  ei  =>•  r,  Mi 

Mi  P  e2  =S  11,  M2 

M  P  *ei  :=  e2  =S  unit,  M2H  1=  r] 

(ALLOC) 

M  P  e  =>■  o,  m' 
r  0  dom(p') 

M  P  ref  e  =>•  r,  mT  1=  r] 

(DEREF) 

M  P  e  =>  r,  m* 

M  |-  *e  =>•  Mir);  M7 

(SEQ) 

M  P  ei  =>  Hi,  Mi 

Mi  P  e2  =P  112,  M2 
//  h  ei ;  e2  =>  t>2,  ^2 

(LOOP) 

(i  h  ei  =>  false,  pJ 

M  P  while  ei  do  e2  =S  unit,  m7 

M  P  ei  =>■  true,  mi 

Mi  P  e2  =S  11,  M2 

M2  P  while  e\  do  e2  =S  unit, 

M  P  while  e\  do  e2  =S  unit,  n' 

(BRANCH) 

M  P  ei  =>  true,  mi 

Mi  P  e2  =S  11,  M7 

M  P  if  ei  then  e2  else  e3  =>•  v, 

M  P  ei  =>  false,  mi 

Mi  P  e3  A  v,  m' 

M  P  if  ei  then  e2  else  e3  =>•  r, 

Fig.  2.  The  evaluation  rules. 
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The  approach  taken  by  Tofte  [1990]3  is  to  prevent  the  generalization  of  any  type 
variables  that  may  occur  in  A'.  In  contrast,  our  system  permits  some  type  variables 
that  occur  in  A'  to  be  generalized.  For  example,  an  expression  such  as 

letvar  x  :=  []  in  r 

allocates  a  location  l  of  type  a  list ;  nevertheless,  we  are  allowed  to  generalize  a. 
The  reason  it  is  sound  to  do  so  is  that  the  expression  evaluates  to  [],  and  (since 
/  does  not  occur  in  [])  we  do  not  need  the  typing  of  l  to  derive  a  type  for  [].  In 
general,  our  system  keeps  track  of  which  variable  locations  may  occur  in  values 
and  prevents  the  generalization  of  type  variables  that  occur  in  the  types  of  these 
locations. 

We  now  proceed  with  the  formal  development  of  the  subject  reduction  theorem. 
First  we  introduce  some  useful  lemmas. 

Lemma  4.1  (Superfluousness).  Suppose  that  A;  7  b  e  :  r.  If  /  dom(  A),  then 
A [/  :  r'];  7  b  e  :  t  and  if  r  dom( A),  then  A[r  :  r'];  7  b  e  :  r.  Also,  if  x  dom( 7), 
then  A;  j[x  :  p]  b  e  :  r. 

Lemma  4.2  (Substitution).  If  A;  7  b  v  :  a  and  A;  7 [a;  :  a]  b  e  :  r,  then  A;  7  b 
[v/ x\e  :  r.  Also,  if  A;  7  b  /  :  r  var  and  A;  j[x  :  r  var]  b  e  :  r',  then  A;  7  b  [1/ x\e  :  r'. 

Lemma  4.3  (V-INTRO).  If  A;  7  b  e  :  a  and  a  does  not  occur  free  in  A  or  in  7, 
then  A;  7  b  e  :  Va  .  a. 

The  preceding  three  lemmas  are  straightforward  variants  of  the  lemmas  given  in 
Harper  [1994].  We  also  need  another  lemma: 

Lemma  4.4.  If  A[/  :  r];  7  b  e  :  t'  and  l  does  not  occur  in  e,  then  A;  7  b  e  :  t' . 

Finally,  we  say  that  l  occurs  m  ihe  range  of  /a  if  /  occurs  in  la(l')  for  some  V  or 
in  fi(r)  for  some  r.  We  can  now  give  the  subject  reduction  theorem: 

Theorem  4.5.  Suppose  that  fi  b  e  =7  v,  /a',  A  b  e  :  r,  fi  :  A,  and  A  assigns  weak 
types  to  all  reference  locations  in  its  domain  and  to  all  variable  locations  that  occur 
in  the  range  of  /a  or  in  a  A-abstraction  in  e.  Then  there  exists  A'  such  that  A  C  A', 
fi'  :  A',  A'  b  v  :  r,  and  A'  assigns  weak  types  to  all  reference  locations  in  its  domain 
and  to  all  variable  locations  that  occur  in  the  range  of  fi'  or  in  v. 

Proof.  The  proof  is  by  induction  on  the  structure  of  the  derivation  of  fi  b  e  =7 
v,n' .  For  brevity,  we  present  only  the  two  most  interesting  cases:  (BIND),  when 
e\  is  not  a  value,  and  (BINDVAR). 

In  the  (BIND)  case,  where  e\  is  not  a  value,  the  evaluation  must  end  with 
A*  b  ei  =>• 

Hi  b  [vi/x\e2  =>  v2,L 2 _ 

fi  b  let  x  =  e\  in  e2  =>  P2 ,  A*2 


3The  same  approach  is  taken  by  Wright  [1992;  1995]  and  SML/NJ  [Greiner  1993;  Hoang  et  al. 
1993],  but  not  by  Leroy  and  Weis  [Leroy  1992;  Leroy  and  Weis  1991]. 
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while  the  typing  must  end  with 

A  b  e\  :  Ti 

A;  [x  :  AppClosex(Ti)\  b  e2  :  r2 
A  b  let  *  =  ei  in  e2  :  T2 

Also,  we  have  fi  :  A,  and  A  assigns  weak  types  to  all  reference  locations  in  its  domain 
and  to  all  variable  locations  that  occur  in  the  range  of  fi  or  in  a  A-abstraction  in  e\ 
or  in  e 2 . 

By  induction,  there  exists  Ai  such  that  A  C  Ai,  /ii  :  Ai,  Ai  b  i>i  :  T\,  and 
Ai  assigns  weak  types  to  all  reference  locations  in  its  domain  and  to  all  variable 
locations  that  occur  in  the  range  of  fi \  or  in  Vi. 

Now  to  apply  induction  again  we  want  to  show  that 

Ai  b  [vi/x\e2  :  r2. 


By  Lemma  4.1  we  have 


Ai ;  [x  :  AppClosex(Ti)\  b  e2  :  r2, 

so  we  can  apply  Lemma  4.2  to  get  what  we  want  provided  that  we  can  show 

Ai  b  i>i  :  AppClosex(Ti). 

Now,  applying  Lemma  4.3  to  Aj  b  dj  :  T\  we  can  get  Ai  b  i>i  :  AppCloseXi(Ti),  but 
this  is  not  good  enough,  because  Ai  may  contain  free  strong  type  variables  that 
are  not  free  in  A.  To  proceed,  we  exploit  our  knowledge  about  what  locations  can 
occur  in  i>i . 

Let  Aj"  be  formed  by  removing  from  Ai  any  typings  l  :  r  such  that  r  is  not 
weak.  By  the  above  use  of  induction,  this  process  does  not  remove  any  typings  of 
locations  that  occur  in  i>i,  as  all  such  locations  have  weak  types.  So  by  Lemma  4.4, 
Aj"  bri  :  T\.  Hence,  by  Lemma  4.3,  Aj"  b  i>i  :  AppClosex(ri),  since  Aj"  contains  no 
strong  type  variables.  Lemma  4.1  then  gives  Ai  b  i>i  :  AppClosex(ri),  and  finally 
by  Lemma  4.2  we  get  Ai  b  [v\/x\e2  :  T2. 

By  the  use  of  induction  above,  Ai  assigns  weak  types  to  all  reference  locations  in 
its  domain  and  to  all  variable  locations  that  occur  in  the  range  of  n\.  Furthermore, 
if  a  variable  location  l  occurs  in  a  A-abstraction  in  [v\/x\e2,  then  either  l  occurs  in 
i>i,  or  /  occurs  in  a  A-abstraction  in  e 2 ■  In  the  first  case,  Ai(7)  is  weak  by  the  above 
use  of  induction;  in  the  second  case,  A (7)  is  weak  by  the  hypothesis,  and  so  Ai(7)  is 
weak  since  A  C  Aj. 

Hence  we  can  use  induction  a  second  time  to  show  that  there  exists  A'  such  that 
Ai  C  A',  H2  :  A',  A'  b  r>2  :  T2,  and  A'  assigns  weak  types  to  all  reference  locations 
in  its  domain  and  to  all  variable  locations  that  occur  in  the  range  of  fi 2  or  in  i>2. 
Since  A  C  Ai  C  A',  we  are  done. 

As  for  the  (BINDVAR)  case,  the  evaluation  must  end  with 

A*  b  ei  =>•  Vi ,  p.1 
l  ^  dom(ni) 

lii[l  :=  vi]  b  [l/x\e2  =>  V2,H2 
fi  b  letvar  x  :=  e\  in  e 2  =>  ^2 ,  2 
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while  the  typing  must  end  with 
A  b  e\  :  Ti 

A;  [x  :  T\  var]  b  e2  :  r2 

If  x  occurs  in  a  A-abstraction  in  e 2  then  T\  is  weak. 

A  b  letvar  x  :=  e\  in  e2  '■  12 

Also,  we  have  /a  :  A,  and  A  assigns  weak  types  to  all  reference  locations  in  its  domain 
and  to  all  variable  locations  that  occur  in  the  range  of  /j  or  in  a  A-abstraction  in  e\ 
or  in  e 2 . 

By  induction,  there  exists  Ai  such  that  A  C  Ai,  /Ji  :  Ai,  Ai  b  iq  :  T\,  and 
Ai  assigns  weak  types  to  all  reference  locations  in  its  domain  and  to  all  variable 
locations  that  occur  in  the  range  of  fi \  or  in  iq. 

Since  l  dom( Ai),  Ai  C  Ai[/  :  iq]. 

Since  Ai[/  :  iq]  b  /  :  iq  var  and  (by  Lemma  4.1)  A 1  [/  :  iq];  [x  :  iq  var\  b  e2  :  72,  we 
can  apply  Lemma  4.2  to  get 

Ai[/  :  Ti]  b  [l/x\e2  :  r2. 

Also,  n\[l  :=  tq]  :  Ai  [/  :  ti]  by  Lemma  4.1. 

Next,  by  the  use  of  induction  above,  Ai  [/  :  ti]  assigns  weak  types  to  all  reference 
locations  in  its  domain  and  to  all  variable  locations  that  occur  in  the  range  of 
fii[l  :=  tq].  Now  suppose  that  a  variable  location  /'  occurs  in  a  A-abstraction  in 
[l/x\e 2-  Then  either  /'  occurs  in  a  A-abstraction  in  e2,  or  else  /'  =  l  and  x  occurs 
in  a  A-abstraction  in  e2.  In  the  first  case,  by  the  hypothesis  A (/')  is  weak,  and  so 
Ai [/  :  Ti](/')  is  weak.  In  the  second  case,  by  the  restriction  on  the  (LETVAR)  rule, 
Ti  is  weak,  and  so  Ai[/  :  Ti](/')  is  weak. 

So  by  a  second  use  of  induction,  there  exists  A'  such  that  Ai[/  :  ti]  C  A',  /i2  :  A', 
A'  b  r2  :  r2,  and  A'  assigns  weak  types  to  all  reference  locations  in  its  domain  and 
to  all  variable  locations  that  occur  in  the  range  of  n2  or  in  i>2.  Since  A  C  Aj  C  Aj[/  : 
Ti]  C  A',  we  are  done.  □ 

Type  soundness  actually  involves  more  than  the  subject  reduction  property.  How¬ 
ever,  it  is  straightforward  to  extend  the  subject  reduction  theorem  to  show  that 
well-typed  programs  cannot  suffer  run-time  type  errors.  This  requires  an  easy 
canonical  forms  lemma  about  the  type  system,  that  tells  us  that  a  closed  value  of 
some  type  has  the  proper  form.  For  example,  a  closed  value  of  type  r  — >■  r'  must 
be  a  A-abstraction.  Harper  [1996]  discusses  this  more  fully. 

5.  DISCUSSION 

One  of  our  primary  objectives  has  been  to  simplify  the  types  of  imperative  programs 
as  much  as  possible.  It  is  often  argued  that  too  much  information  in  types  makes 
them  unsuitable  as  specifications  in  module  interfaces.  This  has  also  been  a  goal 
of  Wright’s  system  based  on  syntactic  values.  His  system  is  a  restriction  of  Tofte’s 
system  in  that  all  type  variables  are  considered  imperative,  regardless  of  whether 
references  are  used.4  To  restore  polymorphism  in  practice,  often  ry-expansion  will 
do.  However,  there  are  cases  when  ry-expansion  does  not  work,  in  particular,  when 


4Indeed,  the  technical  report  [Wright  1993]  describing  this  system  would  be  more  accurately  titled 
“Polymorphism  for  Imperative  Languages  without  Applicative  Types.” 
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computing  polymorphic  procedures  with  imperative  features.  For  example,  in  his 
system,  make  Count  Fun,  expressed  using  let  and  ref,  is  effectively  given  type 

V_a,  _/?  .  (_a  — >■  _/?)  — >■  (_a  —>■  _/?)  x  (unit  —>■  ini). 

Consequently,  the  application  makeCountFun  hd  is  not  polymorphic,  and  restoring 
it  by  ry-expansion  will  not  work,  since  each  time  the  expansion  is  called  a  new 
counter  is  created.  Wright  argues  that  in  practice  when  polymorphic  procedures 
are  computed,  the  computation  is  almost  always  functional,  so  polymorphism  can 
easily  be  restored  by  rj  expansion.  Even  if  rj  expansion  does  work,  there  is  also  the 
issue  of  call-by-name  inefficiency  as  there  is  in  Leroy’s  proposal  for  call-by-name 
polymorphism  [Leroy  1993].  Shared  intermediate  polymorphism  through  partial 
application  of  curried  functions  is  lost.  In  view  of  these  deficiencies,  our  system 
with  letvar  is  an  attractive  alternative.  It  is  relatively  simple  and  greatly  reduces 
the  need  for  weak  types. 

Our  system  is  not  perfect,  however.  The  restriction  on  rule  (LETVAR)  sometimes 
forces  variables  to  be  given  weak  types  unnecessarily.  For  example,  consider  the 
following  function  that  computes  the  Cartesian  product  of  two  lists: 

fun  icart  xs  ys  =  letvar  a  :=  xs  in 
letvar  b  :=  []  in 

while  not  (null  a)  do 

(b  :=  (map  (fn  y  =>  (hd  a,  y))  ys)  @  b; 
a  : =  tl  a) ; 
b 

end  end 

The  mere  occurrence  of  variable  a  in  (fn  y  =>  (hd  a,  y))  forces  it  to  be  given  a 
weak  type.  Hence  the  best  type  we  can  give  icart  is 

V_a,  [3  .  _a  list  —>■  [3  list  —>■  (_a  x  f3)  list, 

even  though  it  should  be  fully  polymorphic. 

Similarly,  the  functional  style  of  programming  that  codes  loops  using  tail  recur¬ 
sion  leads  our  system  to  assign  weak  types  unnecessarily.  This  is  why  we  have 
included  the  while  loop  as  a  primitive  in  our  language. 

We  conjecture5  that  the  restriction  in  the  (LETVAR)  rule  can  be  relaxed  to 

If  x  is  assigned  to  within  a  A-abstraction  in  62,  then  ti  is  weak. 

This  is  similar  to  Edinburgh  LCF’s  restriction  2 ib  [Gordon  et  al.  1979,  p.  49]. 
Proving  soundness  now  requires  a  different  strategy  than  the  one  used  here,  because 
now  variable  locations  with  strong  types  can  occur  in  values,  as  in  examples  like 
letvar  x  :=  []  in  A y.  x. 

Under  the  relaxed  restriction,  function  icart  can  be  fully  polymorphic,  because 
variable  a  is  not  assigned  to  within  (fn  y  =>  (hd  a,  y)).  However,  even  the  re¬ 
laxed  restriction  can  force  weak  types  to  be  introduced  unnecessarily.  For  example, 
a  faster  version  of  icart  can  be  obtained  by  eliminating  list  concatenation: 


5This  conjecture  has  now  been  established  for  a  core  language  with  variables  but  no  references 
[Volpano  and  Smith  1995]. 
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fun  fast_icart  xs  ys  =  letvar  a  :=  xs  in 
letvar  b  :=  []  in 

while  not  (null  a)  do 

(map  (fn  y  =>  b  :=  (hd  a,  y)  ::  b)  ys; 
a  : =  tl  a) ; 
b 

end  end 

The  relaxed  restriction  forces  both  xs  and  ys  to  have  weak  type,  although  it  is  safe 
for  them  to  have  strong  type. 

6.  CONCLUSIONS 

The  type  system  presented  here  is  appealing  in  its  combination  of  expressiveness 
and  simplicity.  It  also  clarifies  the  relationship  between  variables  and  references. 
For  example,  C  has  the  conversion  operator  V  for  taking  the  address  of  a  variable 
or  array  element.  We  can  introduce  V  by  including  the  typing  rule 

A;  7  b  e  :  r  var 
t  is  weak 
A ;  7  b  &  e  :  t  ref 

which  is  nicely  symmetric  to  rule  (L-VAL)  [Volpano  and  Smith  1996].  Finally,  this 
work  has  provided  a  basis  for  polymorphic  typing  in  the  C  programming  language 
[Smith  and  Volpano  1996]. 
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